home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960425-19960715 / 000354_news@columbia.edu _Wed Jul 3 10:24:22 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB

  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id KAA24679 for <kermit.misc@watsun.cc.columbia.edu>; Wed, 3 Jul 1996 10:24:22 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id KAA16698 for kermit.misc@watsun; Wed, 3 Jul 1996 10:24:19 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: file transfer
  8. Date: 3 Jul 1996 14:24:15 GMT
  9. Organization: Columbia University
  10. Lines: 40
  11. Message-ID: <4rdvqf$g9n@apakabar.cc.columbia.edu>
  12. References: <omafxh7spj.fsf@tees.cs.ualberta.ca>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <omafxh7spj.fsf@tees.cs.ualberta.ca>,
  16. Vladimir Alexiev  <vladimir@cs.ualberta.ca> wrote:
  17. : While I transfer from C-Kermit 5A(190) to DOS MS-Kermit 3.14, I notice that
  18. : the packet size oscillates up and down from the initial 9000 to as low as
  19. : 17. This makes so that more than half of the traffic is protocol, not data.
  20. : I don't think the phone line is that bad, and I use a Supra V32bis 14.4
  21. : with LAPM and MNP5. The kermit parameters I use are:
  22. : set baud 38400   ; my files are zipped, so this should be enough
  23. : set flow-control rts/cts
  24. : set block-check 3                       ; 16-bit CRC
  25. : set windows 5
  26. : set receive packet 9000
  27. : set send packet 9000
  28. : set control unprefixed all
  29. : set control prefixed 0 1 3 13 129 131 141
  30. : What can I do to speed this up?
  31. :
  32. You are failing to be properly amazed that your transfers work at all :-)
  33. Kermit reduces its packet length automatically when there is an
  34. error.  A very common cause of errors when you are using long packets is
  35. buffer overruns which, in turn, are caused by a lack of adequate flow
  36. control (are you sure the modem is set for RTS/CTS too?) and/or hardware
  37. problems -- for example, if you have an unbuffered UART and it is generating
  38. interrupts faster than the CPU can service them.  No amount of error
  39. correction in the modem will do any good in a case like this, because the
  40. errors are occurring outside the modem-to-modem connection.  Similar types
  41. of errors can be caused by other processes (including TSRs) that grab CPU
  42. cycles away from Kermit or, worse, turn off interrupts now and then.
  43.  
  44. So Kermit automatically reduces the packet length in order to minimize the
  45. chance of buffer overruns.  Like when you take your Jeep off the road and
  46. put it into 4-wheel drive and first gear to go up a steep bumpy mountain
  47. path.
  48.  
  49. Read the KERMIT.BWR file that comes with MS-DOS Kermit 3.14 -- it talks about
  50. all of these problems in great detail.
  51.  
  52. - Frank